The invention relates generally to a method and logic circuitry for detecting handshaking protocol errors that may occur during asynchronous transfer of data over a data bus. More particularly, the present invention relates to detecting handshaking protocol error conditions and communicating the error conditions to a data sender to enable a subsequent retry of the data transmission.
As illustrated in FIG. 1, data is typically transmitted back and forth between a host computer system or initiator 10 and peripheral devices or targets, such as disk drives 5, tape drives 6, or printers 7, over a data communication bus 15. The data communication bus 15 couples the initiator 10 and the target devices 5, 6, and 7 together and enables the exchange of data between the system and the devices. One type of data communication bus is a Small Computer System Interconnect (SCSI) data bus. A SCSI data bus can be configured in different ways and has several modes of operation. One configuration and mode of operation is known as SCSI wide bus which includes a sixteen bit data bus with associated control signals such as Busy (BSY), Select (SEL), Control/Data (C/D), Input/Output (I/O), Message (MSG), Request (REQ), Acknowledge (ACK), Attention (ATN), and Reset (RST). The SCSI data bus is connected to the initiator 10 via a host adapter 12 and is connected to target devices 5, 6, and 7 via device controllers 8, 9, and 11. Each device controller is matched to the specific type of device connected to the SCSI bus as shown in FIG. 1. The SCSI data bus 15 may be configured to include a plurality of target devices daisy chained together, where both the initiator, and the last target device connected to the bus (furthest from the initiator) are terminated with a bus terminator 16. The bus terminator 16 includes circuitry for regulating the maximum and the minimum voltage levels on the SCSI data bus 15.
Referring to FIGS. 1 and 2, when information is transferred back and forth between the initiator 10 and any one of the plurality of target devices 5, 6 and 7, a handshaking protocol is used to control the transfer of data on the data bus 15 connected therebetween. When transferring data, for example, from the disk drive 5 to the host 10, the protocol commences the data transfer process by loading a data segment 40 on the data bus 15. The protocol then pauses for a period of time defined as the set-up time. The set up time generally provides a predetermined period of time for the data receiving entity to latch the data segment 40 previously loaded on to the data bus 15. Next, the disk drive target 5 asserts a REQ control signal 20 at a time A over a control line of the data bus 15. This REQ control signal 20 is received by the host initiator 10 and indicates to the initiator 10 that data (Data-1) is on the bus 15 and ready for transfer. The initiator 10 then latches the data and replies to the disk drive 5 with an assertion of an ACK control signal 30 at time B. This ACK control signal 30 indicates to the disk drive 5 that the initiator 10 has possession of the data segment 40. Some time after receiving the ACK control signal 30, e.g., at time C, the disk drive 5 deasserts the REQ control signal 20 for removing the data segment 40 from the data bus 15. The initiator 10 senses that the REQ control signal 20 has been deasserted and responds by deasserting the ACK control signal 30 at time D. The above described handshaking protocol steps are cyclically repeated for each successive data segment (byte or word) 40 loaded on the data bus 15 by the disk drive 5 during transfer of a plurality of data segments 40 from the disk drive target 5 to the host initiator 10.
Referring to FIG. 3, generally one problem can occur when either the initiator 10 detects a REQ control signal 20 that was not sent over the bus 15 by the disk drive 5 or the disk drive 5 detects an ACK control signal 30 that was not sent over the bus 15 by the host 10. These false detections of REQ/ACK control signals, 20 and 30 respectively, occur as a result of noise pulse(s) 35 being introduced to the data bus 15. Noise pulses 35 can be introduced to the data bus 15, e.g. at time E, as a result of the bus 15 being exposed to EMI or RFI signals or by virtue of signal reflections occurring as a result of bus impedance mismatch or incorrect termination. Specifically, noise signals that appear on the data bus 15 can occur due to impedance mismatches between the initiator 10 and target devices 5, 6 or 7, or impedance mismatches between each of the plurality of target devices 5, 6 and 7. These noise pulses 35 are problematic to the handshaking protocol established between the initiator 10 and the target devices 5, 6 or 7, in that noise-pulse-induced false handshakes can cause either the initiator 10 or the target devices 5, 6 and 7 to prematurely proceed to the next step of the handshaking data transfer protocol and thereby drop or lose a data sequence within a data block transfer.
By way of example and as illustrated in FIG. 3, in transferring a first data segment 40a from the disk drive 5 to the initiator 10 the drive 5 loads the first data segment 40a on to the data bus 15, pauses for the set-up time, and then asserts a REQ control signal 20 at time A. Next, the initiator 10 asserts the ACK control signal 30 at time B indicating that the initiator 10 has latched the first data segment 40a. Shortly thereafter at time C the drive 5 responds by deasserting the REQ control signal 20 for removing the first data segment 40a from the bus 15. However, when a noise pulse 35 or signal affects the ACK signal 30, as illustrated in FIG. 3, the noise pulse 35 erroneously appears to the disk drive 5 as a deassertion of the ACK control signal 30 by the initiator 10 at time E. This noise pulse 35 occurs prior in time to a nominal deassertion of the ACK control signal 30 by the initiator 10 as at time D (See FIG. 2).
The disk drive 5 then loads a second data segment 40b on the data bus 15 for subsequent transfer to the initiator 10. Meanwhile, despite the presence of the noise pulse 35 on the ACK line, the initiator 10 still has not actually deasserted the ACK control signal 30 associated with the first data segment 40a being transferred and associated therewith. However, the disk drive 5 detects the noise pulse 35 as an asserted ACK control signal 30 associated with the first data segment 40a and erroneously associates this ACK control signal 30 as an acknowledgment by the initiator 10 that it has latched the second data segment 40b at time Z, FIG. 3. Even though the initiator 10 has not latched the second data segment 40b, the disk drive 5 continues on with the handshaking protocol by deasserting the REQ control signal 20 associated with the second data segment 40b at time Y for removing the second data segment 40b from the bus 15. The initiator 10 then deasserts the ACK control signal 30 at time D, which the initiator believes to be associated with the first data segment 40a, in anticipation of the disk drive 5 sending a second data segment 40b. However, in response to the noise pulse 35 on the ACK path 30 the disk drive 5 has already loaded and removed the second data segment 40b from the bus 15. Therefore, the drive 5 erroneously loads a third data segment 40c onto the data bus 15, pauses for the set-up time and asserts the REQ control signal 20 associated therewith at a time F. The initiator 10 then asserts ACK at a time G, and so forth.
Since the initiator 10 missed detecting the second data segment 40b, the initiator 10 will detect subsequent data segments transferred by the disk drive 5 with a one-data-segment 40 shift. This error condition results in the data bus 15 hanging up (stops responding) after the last data segment 40 has been transferred by the disk drive, because the initiator 10 continues to expect one more data segment to be transferred in order to complete the block transfer. Generally, during transfer of data segments 40 from the disk drive 5 to the initiator 10, a plurality of errors can occur as a result of noise pulses 35 being introduced to either the REQ control signal 20 or the ACK control signal 30 from a variety of sources and causes.
Referring to FIG. 4, in order to commence the transfer of a first data segment 40a from the initiator 10 to the drive 5, the drive 5 asserts a REQ control signal 20b at a time H. In this instance, the REQ control signal 20b is redefined as a request from the disk drive 5 for data 40 from the initiator 10. In response, the initiator 10 loads the first data segment 40a on the bus 15 at a time J and then pauses for the set-up time before sending the disk drive 5 an ACK control signal 30b at a time K. In this instance, the ACK control signal 30b is redefined as a signal indicating to the disk drive 5 that a data segment 40 is ready to be transferred to thereto. Shortly thereafter the drive 5 responds by deasserting the REQ control signal 20b at a time L, which is also redefined in this context to indicate to the initiator 10 that the drive 5 has latched or is in possession of the first data segment 40a. Thereafter the initiator 10 deasserts the ACK control signal 30b at a time M for removing the first data segment 40a from the data bus 15. The above described process steps are cyclically repeated for each successive data segment 40 loaded on the data bus 15 by the initiator 10 for transferring a plurality of data segments 40 from the initiator 10 to the disk drive 5 during a data block transfer.
Referring to FIG. 5, by way of further example, in transferring a first data segment 40a from the initiator 10 to the disk drive 5, the initiator 10 loads a first data segment 40a on the data bus 15 at time J, pauses for the set-up time and then asserts an ACK control signal 30b at time K. However, when a noise pulse or error signal 37 appears on the REQ control signal path 20b, as illustrated in FIG. 5, the noise pulse 37 erroneously appears to the host 10 as a deassertion of the REQ control signal 20b executed by the disk drive 5. As a result, the initiator 10 follows the protocol by prematurely deasserting the ACK control signal 30b at a time P, for removing the first data segment 40a from the data bus 15.
Additionally, the falling edge of the noise pulse 37 erroneously appears as a second assertion of the REQ control signal 20b. This erroneous second assertion of the REQ control signal 20b results in the initiator 10 loading a second data segment 40b onto the data bus 15. Even though the disk drive 5 did not actually request the second data segment 40b, the initiator 10 asserts the ACK control signal 30b at a time Q, indicating to the disk drive 5 that a second data segment 40b, as erroneously requested, is ready for transfer to the disk drive 5. Thereafter, the disk drive 5 deasserts the REQ control signal 20b at a time R, which the drive 5 associates with the first data segment 40a, for latching the second data segment 40b. Next, the initiator deasserts the ACK control signal 30b at a time S in order to remove the second data segment 40b from the data bus 15 and to return the bus 15 to an idle state.
In the absence of further noise disturbances introduced to the REQ control signal 20b, the handing shaking protocol is cyclically repeated for transferring subsequent data segments 40 from the initiator 10 to the disk drive 5. However, these subsequent data segments 40 transferred to the disk drive 5 will have a one-data-segment shift. The one-data-segment shift is a direct result of the disk drive 5 initially requesting a first data segment 40a, but actually receiving the first segment 40a and the second segment 40b. This one-data-segment shift causes the data bus 15 to hang upon completion of the data segment 40 transfers.
Generally, when transferring data segments 40 from the initiator 10 to the disk drive 5, a plurality of errors can accumulate as a result of these noise pulses 35 being introduced to either the REQ control signal 20b (FIG. 3) or noise pulses 37 being introduced into the ACK control signal 30b (FIG. 5).
Therefore, a hitherto unsolved need has remained for a method and circuit for detecting handshaking protocol errors occurring during asynchronous transfer of data segments over a data bus. Moreover, a need exists for a method and a circuit that communicates these detected handshaking protocol errors to the sending party, in order to enable a subsequent retry of the data transmission.
An object of the present invention is to monitor a data bus and detect data transfer protocol errors that occur during asynchronous transfer of data over the bus in a manner that overcomes limitations and drawbacks of the prior art.
Another object of the present invention is to communicate a detected handshaking protocol error to either the initiator, e.g. host computer, or the target, e.g. a disk drive, so that a subsequent retry of the data transmission can be attempted.
One more object of the present invention is to provide a detector logic arrangement for detecting errors occurring in a handshake transfer protocol having a plurality of states which are progressively reached during a data transfer handshaking protocol, such that states which are reached out of order indicate the presence of protocol errors on the bus.
In accordance with principles of the present invention, a detector circuit is provided for detecting data transfer protocol errors. The circuit generally monitors the REQ and ACK control lines of the data bus to detect if the control values associated therewith have entered into an undefined logical state. As a nominally correct sequence of REQ and ACK signals are detected on the bus, corresponding states of the error detector circuit remain benign. If a state is reached out of sequence, a handshake protocol error has occurred, and this condition is detected by the detector circuit and may then be signaled to the sending device to enable a data transfer retry.
In one preferred embodiment, a circuit for detecting data transfer protocol errors of the present invention comprises a pair of logical flip-flops, including a first flip-flop logical circuit having a data input D for receiving a REQ control value from the data bus via an inverter. The first flip-flop further includes a clock input which receives an ACK control value from the data bus. The first flip-flop is advanced one clock cycle for each detected rising edge of the ACK control value, and provides a first output value from a non-inverting (Q) output. Additionally, the circuit for detecting data transfer protocol errors includes a second flip-flip logical circuit having an input D for receiving the REQ control value from the data bus. The second flip-flop also has an inverting clock input for receiving the ACK control value from the data bus. With its inverted clock input the second flip-flop is advanced one clock cycle at each falling edge of the ACK control value. The second flip-flop provides a second output value from a non-inverting (Q) output.
If ACK goes high while REQ is low, the first flip-flop puts out an error condition. If REQ is high when ACK goes low, the second flip-flop puts out an error condition. An OR-gate logical circuit receives the output values from the first flip-flop and the second flip-flip and puts out an error value whenever either flip-flop output is true. This error value is communicated to the disk drive controller so that the disk drive can retry the data transmission operation. An alternative preferred embodiment of error detector circuit, preferably for use at a host or initiator unit, provides a complementary error detection capability. If REQ goes false while ACK is false a first flip-flop generates an error signal. If REQ goes true while ACK is true, a second flip-flop generates an error signal. An OR-gate then passes either error signal to the host or initiator unit.
These and other objects, advantages, aspects and features of the present invention will be more fully understood and appreciated upon consideration of the following detailed description of a preferred embodiment, presented in conjunction with the accompanying drawings.